Cube Design Options and Characteristics

When considering a Cube design, there are characteristics of Cubes that lead to different design options. Each design option has its advantages and disadvantages to the application design. The four main Cube design options are:

Monolithic Cube (Scenario Types – 10)

This cube design concept is for small and simple designs. It does not make use of Extensibility and not often recommended for an application of any size or significance. In this design, Scenario Types are likely to be used. This is also a popular choice for ‘Lift & Shift’ applications because the assumption is this design is temporary and will be replaced. If it is not, the Monolithic Cube design is limiting OneStream key functionality such as Extensibility. When it is replaced, the Cube design leverages Extensible options during implementation.

Super Cube – Linked Cubes

This is the cube example used in the Golfstream Reference and Blueprint applications. There is a Parent Cube and the Dimensions of the parent are at a higher level of detail to the Cubes that roll up to it. There is only one level from the Parent to detail Cubes. There can be several detail Cubes, and each can have different Dimension detail. This is the most common design as it makes the best use of Extensibility and allows for the greatest flexibility for later processes.

Paired Cubes

Paired Cubes are combinations of Cubes that allow for Cube interactions between Cubes without being linked. The most common use of this design is to manage Split and Shared Entities. Split Entities are where the same Entity can exist in multiple Cubes. Shared Entities are where the Users can load to the same Entity in multiple Cubes. Since Dimensions can only exist in One Cube, there needs to be a common Entity Dimension that has all Entities in every Cube. That would be assigned to all Cubes.

For each Cube, there will be a second Dimension that has its hierarchy but uses the Base Members of the first Entity Dimension as its Base Members. For each Cube in the original design, two Cubes would be created. All Dimensions must be the same except for the Entity Dimension. One Cube has the Base Entity’s Dimension; the second has the hierarchy Dimension. Then the Cubes must be linked by making the Cube with all Base Entities the child of the other. This effectively creates a Base Cube with all Entities for its Parent. Users would only ever be in the Parent Cube, so they do not see all Entities. While this will not remove the need to copy the data, all data could be copied by a data management job rule. The linking of Cubes must then be done by rules.

Paired Cube Examples

MasterEntities Dimension is the Entity Dimension with a master list of all the Base Entities. All Base Entities are owned and managed by the MasterEntities Entity Dimension.

HoustonBU Entity Dimension contains a hierarchy needed for Houston reporting. However, HoustonBU has HH and SH as Base Entities rolling to the Houston Parent. HH and SH are owned and managed in the MasterEntities Entity Dimension. A relationship is created between MasterEntities and HoustonBU to allow HH and SH to exist in both Entity Dimensions.

CanadaBU follows the same process as HoustonBU. CanadaBU contains a hierarchy needed for Canada reporting. However, CanadaBU has MO and QC as Base Entities rolling to the Canada Parent. MO and QC are owned and managed in the MasterEntities Entity Dimension. A relationship is created between MasterEntities and CanadaBU to allow MO and QC to exist in both Entity Dimensions.

Specialty Cubes

Specialty Cubes are like Monolithic Cubes but are more limited in purpose. They would be used as Administrator Cubes (Driver Cubes, Overrides, or Equity Control) or Specialty Applications (Process Control). The benefit of putting these Cubes as standalone is separating the Cube by defining a different Cube Type property in the Cube and simplicity of security. They can be separated from the rest of the application.